Complexes for version 1-24-11, part 1. #3440
Conversation
…ingTorMap, horsehoeResolution. Fixed bug in mult of complex maps with numbers, bug in homomorphism
…s us to remove the dependency of Polyhedra on IntegralClosure and ReesAlgebra (which in turn was making the incorporatino of the Complexes package quite difficult).
…ll run correctly.
…unctions: status, rank, transpose, nullhomotopy (synonym of nullHomotopy). Allow complex to take a single matrix. Do not compute remainder in one version of nullHomotopy(serious performance degradation). Moved Ext(Module, Module) functionality from the Core to Complexes. Added minimalBetti fixes.
…ree source was incorrect. freeResolution(Strategy => Syzygies) incorrectly handled resolutions of length 0. Tests and doc were updated for these.
|
I noticed what I think is a small bug - I was going to make a separate pull request but maybe it makes more sense to change it as part of this PR: In the "extend" method in ChainComplexMap.m2, lines 795 -- 799 are intended to check if the output of the preceding lines is really a map of chain complexes. However, since line 795 is |
… changed calls in AInfinity to use this simpler algorithm. Also added in doc for associatedGradedRing
|
@d-torrance Any reason why this one Core test is failing? I don't see any artifacts with the failing tests. It runs fine on my mac too... It doesn't seem to me like it uses too much memory either? |
|
This is the failing test: i1 : tests(73, "Core")
o1 = TestInput[/usr/share/doc/Macaulay2/Core/tests/ext-total.m2:1:1]I see that this PR moves some of the Ext code to the |
…orname{Hom}, imported a test from Core related to total Ext
The problem seemed to be the changes we made in nullHomotopy. The general case was slower (and probably took significantly more memory), so we added in the keyword FreeToExact in two calls to nullHomotopy in Ext(Module,Module). However, with that change, the code would not run on the version before Complexes is loaded. So we moved the test to where it should be anyway (and occurs after Complexes is loaded). |
|
After this is merged, we will make a second PR that fixes about 8-10 of the packages, the ones that require mostly trivial changes. After that, another group... continuing as in the first comment of this PR. |
…then displays that the argument is a complex, a complex, a module (doubled complex). It appears that is a bug that will get fixed before the next version, so we change this to be correct once that bug fix is in.
|
I made the small doc changes. The github tests are rerunning. |
|
I think this is ready to merge. Should I do it or do you want to? |
|
@d-torrance What else should we do before this PR is merged? |
|
Looks good to me! |
|
Should I just do the merge? Should I do "rebase and merge"? Will that screw up future PR's based on the same branch? |
|
Oops, all merged! Thanks! |
|
No problem! Using the same branch for future PR's should be fine. |
|
@mikestillman, @ggsmith: Do you have any suggestions for how the complexes changes should be described in the changelog for the new release? |
This is the first PR for converting the ChainComplex and ChainComplexMap types from the Core to the types Complex, ComplexMap in Complexes package. Here are the steps we envision to do the switch:
m2/res.m2,m2/chaincomplexes.m2, and move/remove documentation and tests from the Core.